Skip to main content
Version: Next

Pull Request Guidelines

PR Title Format​

Follow this exact format for consistency:

[Team] | iOS | [Type] | [Ticket] | [Description]

Components:

  • Team: Your team name (e.g., Base, Avengers, Ravenclaw, Miyagi ThinKs)
  • Platform: Always "iOS" for this project
  • Type: Task, Bugfix, Feature, TechDebt, etc.
  • Ticket: Full ticket number (e.g., PLATT-36143)
  • Description: Brief description of changes

PR Title Examples​

Base | iOS | Task | PLATT-36143 | Add Sentry logs for unauthorized requests
Avengers | iOS | Task | PLATT-36139 | Show monetary bonus value on goal card
Miyagi Thinks | iOS | Bugfix | PLATT-24500 | Fix same state event name in challenges
Ravenclaw | iOS | Task | PLATT-35963 | Vorsorgekompass - Add infocard for colon cancer

Pre-PR Checklist​

Before opening a Pull Request, ensure you complete the following:

✅ Code Quality​

  • SwiftLint validation passed - Run ./Pods/SwiftLint/swiftlint in NavidaProPlugins directory
  • SwiftFormat applied - Run ./Pods/SwiftFormat/CommandLineTool/swiftformat . if available
  • Unit tests added for ViewModel logic and business logic
  • Snapshot tests updated if UI components were modified
  • No compiler warnings in your changes

✅ Code Integration​

  • Branch is up-to-date with develop branch
  • Merge conflicts resolved if any exist
  • Plugin independence maintained - verify minimal cross-plugin dependencies
  • Deep link patterns followed for navigation (if applicable)

✅ Documentation​

  • PR description includes detailed explanation of changes
  • Screenshots included for UI changes
  • Breaking changes documented if any
  • Plugin-specific documentation updated if needed

✅ Security & Compliance​

  • No hardcoded secrets or sensitive data
  • Data privacy compliance maintained

Plugin-Specific Considerations​

Given our modular plugin architecture, consider these additional guidelines:

Plugin Independence​

  • Avoid direct dependencies between plugins
  • Use the DeepLinkManager for inter-plugin communication
  • Maintain plugin-specific test coverage

Plugin Development​

  • Follow existing plugin patterns in your target plugin
  • Update plugin configuration if adding new screens or features
  • Ensure proper plugin lifecycle management

Environment Considerations​

When working across different environments (Dev, Prod, SAPM, SAPW, etc.):

  • Test changes across relevant environments
  • Verify configuration-specific behavior
  • Update environment configs if needed

Review Process​

  1. Self-review your changes before requesting review
  2. Request review from appropriate team members
  3. Address feedback promptly and thoroughly
  4. Verify CI/CD passes all checks
  5. Merge only after approval and successful builds